Method and system for determining allied products

ABSTRACT

The method comprises processing plural product information records from the product information sources into one or more groups based on which product information records are likely to correspond to the same product, correlating a unique product ID corresponding to the product associated with each of said groups to identify the product, comparing each identified product to categories of a taxonomy to determine a category for the identified products in the taxonomy, and determining attributes for each categorized product based on the product information records corresponding to each group, creating product specifications based on the determined attributes and storing the product specification in the corresponding determined categories of the taxonomy.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.14/869,399 filed Sep. 29, 2015 (pending), which is a continuation ofU.S. application Ser. No. 13/229,217 filed Sep. 9, 2011 (U.S. Pat. No.9,177,059 issued Nov. 3, 2015), which is a continuation of U.S.application Ser. No. 11/471,707 filed Jun. 21, 2006 (now abandoned),which is a continuation of U.S. application Ser. No. 10/659,740 filedSep. 11, 2003 (U.S. Pat. No. 7,082,426 issued Jul. 25, 2006), which is acontinuation-in-part of U.S. application Ser. No. 10/119,311, filed Apr.10, 2002 (U.S. Pat. No. 6,714,933 issued Mar. 30, 2004), which is acontinuation-in-part of U.S. application Ser. No. 09/566,734, filed May9, 2000 (U.S. Pat. No. 6,535,880 issued Mar. 18, 2003), the disclosuresof which are incorporate herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates to systems for creating catalogs of goods andservices over a communications network. More specifically, the inventionis directed to a method and system for aggregating content for anon-line catalog system.

2. Description of the Related Art

The Internet is a worldwide network of computers linked together byvarious hardware communication links all running a standard suite ofprotocols known as TCP/IP (transmission control protocol/Internetprotocol). The growth of the Internet over the last decade has beenexplosive, fueled in the most part by the widespread use of softwareviewers known as browsers and HTTP (hypertext transfer protocol) whichallow a simple GUI (graphical user interface) to be used to communicateover the Internet. Browsers generally reside on the computer used toaccess content on the Internet, i.e. the client computer. HTTP is acomponent of TCP/IP and provides users access to files of variousformats using a standard page description language known as HTML(hypertext markup language), and more recently XML (extensible markuplanguage) and XHTML (extensible hypertext markup language), areformulation of HTML into XML. The collection of servers on theInternet using HTTP has become known as the “World Wide Web” or simplythe “Web.”

As known and appreciated in the art, there are presently millions of Webpages with various content. Tools have been developed to allow the userto search these Web pages to obtain the various Web pages having thevarious content of interest. One way to locate the desired Web pages isto use a “search engine” which will search for Web pages having aparticular keyword or key words. Search engines typically have threecomponents: a crawler (such as a robot, bot or automated site searcher),an index, and a software program which presents the results of thesearch to the user. The crawler automatically “crawls” from Web serverto Web server and the sites hosted therein to gather URLs and otherinformation such as the text of the page that the search engine can usein the searches for keywords. When the information gathering by thecrawler is completed, the information regarding the Web pages is storedin the search engine's databases and indexed. When a user seekinginformation from the Web types in a keyword(s) in a search field of thesearch engine, the search engine's software program then utilizesalgorithmic functions and criteria to find keyword matches in theinformation stored in the databases. Some programs search all of thetext of each page while other programs merely search the URLs and/ortitles of the pages. The software program then sorts through the resultsof the search and provides a prioritized results to the user based onrelevancy of the Web page. Various search engine software programsdiffer in their methods used for determining a Web page's relevancy. Forexample, the software may view the “meta tag” of the page, include acounter for counting the number of keyword occurrences on the text ofthe page, and/or consider the Web page's popularity as well as otherfactors such as whether the Webmaster of the Web page has made specialarrangements to have the Web page displayed as a result of the search.

One of the primary applications of the Web has been shopping, i.e. thepurchase of goods and services, i.e. products. Virtually every majorcommercial “bricks and mortar” merchant has established a Web site forthe showcase and sale of their products. Further many manufacturers sellproducts directly over the Web. Finally, a plethora of on-linemerchants, not previously existing in the bricks and mortar world, havecome into existence. As a result, virtually every product is availablefor purchase over the Web from a plurality of merchants. This situationhas increased the efficiency of markets by permitting shoppers toreadily compare products and terms of sale from plural merchants withoutthe need to travel physically to the merchant locations.

However, in order to compare products and terms of different merchants,one must “visit” the various merchant web sites individually. First,this requires knowledge of the URLs for each merchant Web site or theuse of a search engine which can be cumbersome and inaccurate. It ispossible to open the various sites in different browser windows forbetter comparison. However, the various formats of each merchant Website render it tedious to compare products and terms directly. When apurchase decision is made, the purchase or purchases must be madethrough the individual merchant Web sites. Further, ordinarily theshopper is required to log in to each merchant Web site, by entering ausername and password for example, prior to making a purchase and thenproceed to the next site. For example, if the shopper decides to buythree items from three different merchants, three log in procedures andthree buy procedures, i.e. procedures for effecting a purchase on themerchant Web sites, must be manually executed respectively through thethree merchant Web sites and their proprietary interfaces.

It is well known to integrate a plurality of web sites into a singleenvironment known as a “shopping portal.” Shopping portals ordinarilyinclude a Web server presenting an integrated interface displayingplural products from various merchants. Accordingly, conventionalshopping portals facilitate comparison shopping and thus increase marketefficiency. In order to provide an integrated shopping experience, it isknown to prepare a catalog of product offerings from various merchantsorganized in a taxonomy of product categories. However, since variousmerchants and other parties having product information records all storeinformation in various data formats and layouts, collection ofinformation for a product catalog is a tedious and labor intensive taskrequiring a great deal of manual operations.

SUMMARY OF THE INVENTION

An aspect of the invention is a method of creating a product catalogstored on computer readable media by aggregating product informationfrom a plurality of product information sources having disparate formatsfor product information and storing the information in a taxonomy. Themethod comprises processing plural product information records from theproduct information sources into one or more groups based on whichproduct information records are likely to correspond to the sameproduct, correlating a unique product ID corresponding to the productassociated with each of said groups to identify the product, comparingeach identified product to categories of a taxonomy to determine acategory for the identified products in the taxonomy, and determiningattributes for each categorized product based on the product informationrecords corresponding to each group, creating product specificationsbased on the determined attributes and storing the product specificationin the corresponding determined categories of the taxonomy.

BRIEF DESCRIPTION OF THE DRAWING

The invention is described through a preferred embodiment and theattached drawings in which:

FIG. 1 is a block diagram of a computer architecture in accordance withthe preferred embodiment of the invention including a plurality ofmanufacturers' servers;

FIG. 2 is a block diagram of a portion of the architecture of FIG. 1schematically illustrating the communication channel connections for anautomated purchase procedure;

FIG. 3 is a block diagram of the cookie handling procedure of thepreferred embodiment;

FIG. 4 is a schematic representation of the internal automated purchaseprocedure of the shopping server of the preferred embodiment.

FIG. 5 is a block diagram of a method in accordance with one embodimentof the present invention for processing the gathered product propertyinformation from the plurality of manufacturers' servers;

FIG. 6 is a block diagram of a method in accordance with one embodimentof the present invention for validating the product offerings of on-linemerchants and for creating a new product record based on the determinedproduct properties.

FIG. 7 is a schematic illustration of a catalog taxonomy of thepreferred embodiment;

FIG. 8 is a schematic illustration of a property definition tool ofanother preferred embodiment; and

FIG. 9 is a flowchart of the operation of the property definition toolof FIG. 8.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

A preferred embodiment of a computer architecture for providing anintegrated on-line shopping experience and product catalog generation isillustrated in FIG. 1. Commerce system 10 includes client computer 12executing browser application 14 that supports the HTTP protocol. Clientcomputer 12 is connected, typically through an ISP (Internet ServiceProvider), to Internet 100 serving as a communication channel. Forexample, client computer system 12 can be coupled to the ISP via aconventional dial up connection using a modem or through a broadbandconnection such as ISDN (Integrated Services Digital Network), a cablemodem, or a DSL (Digital Subscriber Line) connection. Shopping server 20is also coupled to Internet 100 in a known manner. Shopping server 20executes a Web server control application 22, known as an HTTP serverapplication, stored in a memory device. For example, public domain webserver software applications from NCSA or APACHE can be used. Shoppingserver 20 also executes agent server control application 24, (thefunction of which is described in detail below) utilizing a secureconnection for privacy.

A plurality of merchant servers 40 provide on-line shopping usingconventional commerce server control applications, i.e. software thatruns some of the main functions of an online storefront such as productdisplay, online ordering, and inventory management. Merchant servers 40and commerce server software are well known and thus are not describedin detail herein. Further, merchant servers 40 can store productinformation records including information about product offerings.

In the preferred embodiment, each of client computer 12, shopping server20, and merchant servers 40 are capable of communicating using a secureconnection protocol, such as SSL or S-HTTP. For clarity, non secureconnections 30 and secure connections 32 are illustrated separately.However, typically, these connections will be effected over the samephysical connection or communication channel, such as Internet 100.Further, shopping server 20 and merchant servers 40 can have many Webpages stored in memory devices thereof as files in HTML format and/orother formats. Shopping server 20 also includes product catalog 26 andshopper database 28 stored in a memory device thereof as described indetail below.

Client computer 12 can request a display of a Web page stored onshopping server 20 by issuing a URL request through Internet 100 toshopping server 20. For example, a user of client computer 12, i.e. ashopper, can select a product, or plural products, for purchase bynavigating Web pages stored on shopping server 20 and populated withproduct information from product catalog 26. Product catalog 26 can bein the form of a database and can include product descriptions, pricingand other product information for plural merchants and culled frommerchant servers 40 using automated Web crawlers as described in detailbelow. The product information in product catalog 26 should be updatedperiodically to correspond with current product information on merchantservers 40. However, as will become apparent below, the productinformation need not be updated in real time.

The product information from product catalog 26 can be searched anddisplayed by product type, part numbers, price, keywords, or productfeatures in any desirable manner using an interface of shopping server20 as presented to the shopper by browser application 14 on clientcomputer 12. The product information in product catalog 26 relating toproducts from plural merchant servers 40 can be displayed side by sidein the browser window of client computer 12 to permit the shopper tocomparison shop and choose products from any one or more of merchantservers 40 based on the product information. For example, the user maysearch for all instances of a particular item by product name or partnumber and may select for purchase the instance from the merchant havingthe lowest price. Upon logging in to shopping server 20, by entering ausername and user id as identification data for example, a user can beidentified and thus can avoid the need for reentering previouslyregistered data and preferences.

FIG. 2 schematically illustrates the communications channel connectionsof the preferred embodiment during an automated purchasing procedure.For the sake of clarity, the remaining description refers generally toonly one merchant server 40. However, it should be understood that theprocedure described below can be accomplished for plural products fromplural merchant servers 40. When a user selects a product for purchase,by clicking on a “buy” button for example, secure connection 32 isestablished between client computer 12 and agent server application 24of shopping server 20. Agent server application 24 then opens parallelsecure connection 32 with the commerce server application of merchantserver 40. Secure connections 32 are illustrated as direct connectionsbetween computers for clarity. However, it should be understood thatsecure connections 32 can be SSL connections over Internet 100 or anyother type of communication channel.

Also, as illustrated in FIG. 2, first “cookie” 29 (i.e. a filecontaining information, such as identification information, to be usedby a server) is established on shopping server 20 and second cookie 18is established on client computer 12. First cookie 29 allows merchantserver 40 to track status of its order acceptance process and secondcookie 18 allows shopping server 20 to track status of its orderplacement process. With reference to FIG. 3, first cookie 29 containsinformation identifying the order acceptance session between shoppingserver 20 and merchant server 40, i.e. a merchant session ID. Theidentifying information can be any character string or code by whichmerchant server 40 can identify the order acceptance session. Similarly,second cookie 18 contains a “nonce” (i.e. a one-time random string), orother information identifying the order placement session between clientcomputer 12 and shopping server 20. Shopping server 20 maintains record55, such as a database or a lookup table, that associates the nonce ofsecond cookie 18 with the corresponding transaction record 54 (seedescription of FIG. 4 below), by pointing to the transaction record 54for example. Changes in transaction reporting from merchant server 40are recorded in transaction record 54 because the two are synchronizedby virtue of pointers from the nonces to transaction record 54.Transaction record 54 also contains the corresponding merchant sessionID. Accordingly, when the shopper resumes an idle session, such as byconfirming an order through client computer 12, shopping server 20examines second cookie 18 and identifies the corresponding orderplacement session and status and is thus able to resume the session in asecure manner. Further, shopping server 20 will locate the correspondingfirst cookie 29 and present it to merchant server 40 to resume thecorresponding order acceptance session.

Keep in mind that there typically are a plurality of order placement andcorresponding order acceptance sessions occurring simultaneously. Thecookie management procedure described above allows all sessions to becorrelated properly and thus permits a seamless shopping experience.Shopping server 20 uses information stored in shopper database 28 to acton the shopper's behalf during execution of a buy procedure of merchantserver 40. Shopper database 28 can include any appropriate informationabout registered shoppers, such as their name, address, shoppingpreferences, credit card numbers, merchant account information (such asa username and user id for the shopper at each particular merchant), andthe like. Of course all data in shopper database 28 can be collectedduring a registration procedure and encrypted for security in a knownmanner.

FIG. 4 illustrates the purchase procedure, i.e. the function of agentserver 24, of shopping server 20 in greater detail. Keep in mind thatthe purchase procedure ordinarily begins after the shopper has logged into shopping server 20 or otherwise identified themselves uniquely. Thefirst phase of the purchase procedure permits the shopper to searchproducts in catalog 26, browse for products in various ways, and selectone or more products for purchase from one or more merchant servers 40.After logging in, main process 50 of agent server control application 24generates buy form 52 for display to the shopper. In the event that theshopper desires to change information in buy form 52 for the currentpurchase procedure, the shopper can merely edit buy form 52. Forexample, the shopper may wish to change the shipping address or shipmentmethod. Of course, the shopper profile can be edited to change thedefault shopper information in shopper database 28. Buy form 52 isautomatically pre-filled with default shopper information correspondingto the shopper if such information exists as a shopper profile inshopper database 28. If such information does not exist for the shopper,the shopper can be prompted to enter the information and the informationcan be used in the current purchase procedure. Main process 52 alsocreates transaction record 54 which keeps track of all transactioninformation, including transaction status, for the current transactionprocedure (such as credit card information, billing addresses, and thelike from shopper database 28 and merchant SKUs of selected products,shipping options, and the like from product catalog 26).

Also, main process 50 spawns buy process 56 and points buy process 56 tothe corresponding transaction record. As the shopper selects variousproducts and options using the browser interface of client computer 12,transaction record 54 is updated. Note that, at any given time, therecan be plural purchase procedures for plural shoppers each having arespective buy process 56 and corresponding transaction record 54. Buyprocess 56 will continue to run in parallel with main process 50 untilthe purchase procedure is completed. Buy process 56 continually updatestransaction record 54 based on shopper selections. Meanwhile, mainprocess 50 polls transaction record 54 for updated status. In thismanner, main process 50 is updated with the status of each purchaseprocedure.

When the first phase of the purchase procedure is complete, i.e. theshopper has selected all desired products and options from all desiredmerchants, main process 50 presents confirmation page 58 to the shopper,through the browser interface of client computer system 12, forverification of an order by the shopper. Confirmation page 58 isgenerated by communication between shopping server computer system 20and the appropriate merchant server 40 using secure connection 32between shopping server computer system 20 and the appropriate merchantserver 40. In particular, shopping server computer system 20 uses theinformation in transaction record 54 to verify pricing information,shipping information, and other details of the desired purchase withmerchant server 40 by automatically going to each merchant checkoutpage, or other information page, and retrieving the updated information.Buy procedures of merchant server 40 are integrated into buy processesof shopping server 20 to allow buy process 56 to automatically navigatemerchant server 40. Back end test scripts or the like can be used todetermine the particular buy procedure steps of merchant server 40.

If account information for a particular merchant exists for the shopperin shopper database 28, that account information is used when executingthe buy procedures with the merchant server 40. If not, a new account iscreated for the shopper with the merchant and the account information isstored in shopper database 28 for subsequent use. Since shopping server20 uses merchant account information that corresponds to the shopper,the shopper can retain preferred buyer points and other benefits anddiscounts as if shopping directly at merchant server 40.

Keep in mind that, in the preferred embodiment, up to the time ofgenerating confirmation page 58 communication has been between clientcomputer system 12 and shopping. server 20 using information fromproduct catalog 26, which might not be entirely updated due to the fluidstate of on-line commerce. Accordingly, confirmation page 58 includesreal-time pricing and shipping information obtained from merchant server40 for each selected product in transaction record 54. Upon receivingshopper confirmation of the order summarized in confirmation page 58,all transaction information in transaction record 54 is saved and secondcookie 18 is saved to allow the procedure to restart later on with thesame user session. Buy process 56 remains idle while waiting for theshopper to confirm the order by selecting a button on confirmation page58 or taking other action.

In the second phase of the purchase procedure, the purchase transactionis completed. In particular, second cookie 18 is used to resume theprevious user session on merchant server 40. Subsequently, the order isexecuted on merchant server 40 using information in transaction record54 to run a buy procedure and thus execute a buy process, on merchantserver 40. The order is then confirmed on shopping server 20,transaction record 54 is updated and receipt page 60 is generatedshowing the transaction information and confirmation numbers and thelike from merchant server 40. Once again, it is important to note thatproducts can be selected from plural merchant servers 40 and, in such acase, plural buy procedures will be executed and confirmed on therespective merchant servers 40 using the appropriate shopper accountinformation automatically for each merchant server 40.

It can be seen that the purchase procedure discussed above permitsshopping server 20 to act on as an agent behalf of the shopper ininteractions with merchant servers 40. However, some merchants do notfeel comfortable with shoppers using an agent Web site. In particular,many merchants rely on advertising, affiliate programs, and the like intheir business model and thus can only accomplish their businessobjective if the shopper “visits”, i.e. directly views, their Web siteand its buy pages in particular during shopping. Accordingly, a proxyserver mode of shopping server 20 can be used to offer many of theadvantages of the integrated purchasing procedure disclosed above, whilesatisfying vendors that desire to have the shopper visit their Web sitebuy pages.

Internet proxy servers are well known. The phrase “proxy server” refersgenerally to a server that sits between a client application, such as aWeb browser, and a Web server to intercept requests. The proxy serverthen serves up substantially the same content as the Web server to whichthe request was directed while also performing an auxiliary functionsuch as filtering data, monitoring data, or serving up a cached copy ofthe Web page. In the preferred embodiment, this general concept isexpanded and applied to an integrated shopping environment. In proxyserver mode, parallel secure connections 32 are set up between clientcomputer and shopping server 20 and between shopping server 20 andmerchant server 40, as illustrated in FIG. 2. The first phase of thepurchase procedure is accomplished in the same manner as described abovewith respect to the standard mode. To utilize proxy server mode,merchant database 28 preferably includes form maps for mapping fields inthe order forms of merchant server 40 to fields in shopper database 26.An external editing tool can be provided to develop the form maps in aknown manner. For example, the editing tool can be configured to readthe HTML forms and parse out the data fields. These data fields can thenbe correlated to corresponding fields in custom database 28.

During the second phase of the purchasing procedure, when clientcomputer 12 requests a Web page from merchant server 40, shopping server20 (in proxy server mode) handles the request and filters out the HREFs,i.e. HTML document references, and POSTs, i.e. HTML form submissions, topoint to shopping server 20 instead of merchant server 40. When merchantserver 40 sends a blank form to client server 12, the form isintercepted by shopping server 20 and the form is filled out withinformation from shopper database 26. When client computer 12 posts aform back to merchant server 40, shopping server 20 reproduces the postkeeping intact all changes in the form content made by the shopper.First cookie 29 and the second cookie 18 track the sessions as describedabove.

In proxy server mode, when the shopper selects a buy button fromconfirmed page 58 or another page displayed on client computer 12, theshopping cart page, or other buy page, of merchant server 40 isdisplayed. The shopper manually executes the buy procedure of merchantsever 40 using the interface of merchant′ server 40 as displayed onclient computer 12. This manual procedure is accomplished for eachmerchant server 40 requiring the proxy mode. Accordingly, in proxyserver mode, the shopper views all the buy pages and executes the buyprocedures on merchant server 40. However, shopping server 20 mediatesand assists in filling out forms. Other aspects of the purchaseprocedure using proxy server mode can be similar to the purchaseprocedure described above without proxy server mode.

The invention facilitates on-line commerce by permitting an integratedbuying experience from plural merchants. The invention can beimplemented over any type of communications channel, such as theInternet,—a local area network (LAN), a wide area network (WAN), directcomputer connections, or the like, using any type of communicationhardware and protocols. Any type of hardware or combination of hardwarecan be used for the various clients and servers. Accordingly, the term“computer” as used herein, refers to any type of computing device ordata terminal, such as a personal computer, a portable computer, a dumbterminal, a thin client, a hand held device, a wireless phone, or anycombination of such devices. The various clients and servers can be asingle computer at a single location or multiple computers at a singleor multiple locations. For example a server may be comprised of aplurality of redundant computers disposed in co-location facilities atvarious locations to facilitate scalability. Any appropriate server orclient software can be used and any communication protocols can be used.Communication can be accomplished over electric cable, fiber opticcable, any other cable, or in a wireless manner using radio frequency,infrared, or other technologies. Any interface can be used for selectingproducts for purchase. The various information can be stored in anyformat and thus the term “database” as used herein refers to anycollection of information such as a database file, a lookup table, orthe like.

As noted, product catalog 26 can include product descriptions, pricing,delivery dates, and other product information for plural merchants. Suchproduct information may be culled from product information records ofvarious sources by using automated crawlers as described below andupdated periodically to correspond with current products available onmerchant servers 40. The term “crawler” as used herein refers to anysoftware that performs searches of content over a network and caninclude “bots”, “robots”, “automated site searchers” and the like.Referring again to FIG. 1, commerce system 10 includes client computer12 executing browser application 14 and shopping server 20 whichexecutes agent server control application 24, client computer 12 andshopping server 20 being connected to Internet 100 which serves as acommunication channel. In addition, in the preferred embodiment,plurality of manufacturer's servers 44 are also connected to Internet100 via non secure connections 30. In this regard, shopping server 20may be used to aggregate product information from a plurality of sourcesconnected to Internet 100 regarding products of a product category andstore the aggregated information in product catalog 26 in the form of ataxonomy. However, it should be noted that the aggregation of productinformation may be attained using a computer that is separate from thecomputer running agent server central application 24 and the resultinginformation can be made available to the computer running agent servercentral application 24.

FIG. 7 illustrates an example of taxonomy 700 of product catalog 26.Taxonomy 700 includes 1st tier categories 714, 2nd tier categories 716,3rd tier categories 720, and product specs, i.e., specifications, 718and 722. Note that taxonomy 700 is defined by a tree-like structure inwhich categories include attributes that define a spec for productswithin the categories. Product spec 718 and 722 inherit the attributesof the parent category and can include values for the attributes andapplicable units of measure.

The plurality of sources may include a plurality of merchants'information sources and manufacturers' product specification sourcesthat are hosted in merchants' servers 40 and manufacturer's servers 44respectively. It should be appreciated that in the preferred embodiment,the plurality of merchants' information sources are merchants' Web pages42 and the manufacturers' product specification sources aremanufacturers' product specification Web pages 46. Additional sources ofproduct information records can be various product literature sourceswhich may be product literature Web pages that review and provideadditional information regarding a product or products of a productcategory. In fact, the manufacturers' product specification sources canbe considered to be merely a subset of the product literature sources.Also, when manufacturers sell products directly over Internet 100,manufacturer's servers 44 are one in the same as merchant's servers 40.

In accordance with the preferred embodiment, the shopping server 20 isoperative to provide at least one crawler for visiting the plurality ofsources hosted by, for example, merchants' servers 40 and manufacturer'sservers 44 to aggregate product information from these plurality ofsources regarding various products of a product category. The crawlermay include product literature crawler 72 that gathers-product phraseinformation from the manufacturer's product specifications Web pageshosted by manufacturer's server 44. The crawler may also include productofferings crawler 74 that gathers product phrase information and pricinginformation of each of the products in the product category from themerchant's Web pages hosted by merchant's servers 40. Of course, itshould also be noted that product literature crawler 72 may also visitmerchant's Web pages and product offerings crawler 74 may also visitmanufacturer's product specifications Web pages. Moreover, a singlecrawler may be provided to perform the functions of both productliterature crawler 72 as well as product offerings crawler 74. Any typeof number of crawler can be used.

In the preferred embodiment, product literature crawler 72 and/orproduct offerings crawler 74 may gather information form product catalog26 regarding a manufacturer's identity and product model, as well as theproduct phrase information which preferably includes a phrase and atleast one characteristic of the phrase from each of the plurality ofsources by utilizing computational linguistics. It should be understoodthat the term “phrase” which is gathered by crawlers 72 and 74 refers toan alpha-numeric character string or strings present in a source such asmanufacturer's product specifications Web pages 46, merchant's Web pages42, and/or product literature Web pages (not shown). The term“characteristic” refers to some attribute of the alpha-numeric characterstring in the Web page. For instance, the characteristic of the phrasemay be its frequency, location, font size, font style, font case, fonteffects, and font color of the phrase in the Web page as well as thefrequency of collocation (phrases immediately next to each other) andco-occurrence of phrases (phrases within a predetermined words of eachother). Moreover, the term “computational linguistics” is used herein torefer to a cross-disciplinary field of modeling of language utilizingcomputational analysis to process language data such as any of the abovenoted characteristics of the phrase. In the preferred embodiment,crawlers 72 and 74 and the computational linguistics used thereby aresoftware programs designed to execute the functions described. Thus, byutilizing computational linguistics, product literature crawler 72and/or product offerings crawler 74 gathers product phrase informationwhich may be processed and used in the manner described below.

In accordance with the above discussion, FIG. 5 illustrates the methodof the preferred embodiment of the present invention where productliterature crawler 72 obtains product phrase information utilizingcomputational linguistics module 75. The obtained product phraseinformation (i.e. the phrase and the characteristic of the phrase) arethen stored in product phrase database 76 for further analysis. Commercesystem 10 of FIG. 1, via shopping server 20 or by other means such asanother computer/server, is operable to further analyze the productphrase information using statistical analysis module 78 to therebyprovide a ranking of the product phrases in any given product category.These ranked product phrases will typically represent commonly foundproduct properties of a given product or product category and are alsostored in the product phrase database 76.

In addition, as will be described in further detail below, the preferredembodiment of the present invention utilizes property definition tool 80to analyze the stored product phrase information to thereby determinewhether each of the product phrase information in product phrasedatabase 76 is in fact a product property. It should be understood thatthe term “product property” or “product properties” can be a word,number, phrase, or combination thereof, that descriptively characterizesthe product or product category. Property definition tool 80 of thepreferred embodiment is a software algorithm, running on shopping server20 or another device, illustrated as steps in FIG. 5.

Thus, for example, product literature crawler 72 may examine the contentof Web page 46 of manufacturer's server 44 such as a computermanufacturer (or other server having a product literature source) toobtain product phrase information provided on the Web page including thephrase and the characteristic(s) of the phrase as well as informationprovided in the Web page's URL address and any meta tags. This productphrase information can then be stored in product phrase database 76 forfurther analysis. In this example, the computer manufacturer's home Webpage will likely have a meta tag including the phrase “computer” as wellas the phrase “computer” throughout its home Web page which may or maynot have special characteristics such as formatting and positioningwhich distinguishes the phrase from the remainder of the text on the Webpage. Because of the use of computational linguistics module 75, productliterature crawler 72 is able to recognize and obtain such informationregarding the phrase “computer” such as its presence in the home Webpage's meta tag, frequency in its home Web page, and its other specialcharacteristics to thereby statistically discern that the home Web pagesrelates to computers and that the Web pages linked to the home Web pagewill also likely relate to computers and consequently, determine thatthis phrase is a product property, in particular, a product category.

More preferably, product literature crawler 72 may also crawl through asubstantial portion of the linked Web pages prior to determining whetherthe phrase is a product property to ensure accurate determination. Forinstance, product literature crawler 72 may crawl through the pluralityof Web pages linked to the home Web page to gather product phraseinformation and in the present example, will further likely identifypresence of the phrase “computer” as well as other phrases known to beassociated with a given product category such as phrases “Mb RAM” whichis a collocated phrase, “MHz”, “floppy”, and/or “Gb”, etc. Based onanalysis of the frequency and characteristics of such phrases bystatistical analysis module 78, the phrase “computer” can be determinedto be a product property that defines a product. category. In thisregard, separate category database 79 may be provided with variousproduct categories and the likely associated key word phrases which maybe cross referenced to ensure the accuracy of the product categorydetermination. Furthermore, in addition to, or as an alternative tocategory database 79, a human verification process may be provided tofurther ensure accuracy of the product category determination.

In addition, the plurality of Web pages linked to the home Web page willalso typically include alpha-numeric character strings, i.e., datastrings, that identify other important characteristics of the product orproduct category. Again, it should be noted that such significantcharacter string will often be distinguished from the remaining text ofthe Web page by its location on the Web page, formatting or othercharacteristic of the character string. For instance, the characterstrings may be positioned near the top or the left hand side of the Webpage and have a larger font size than most of the other characterstrings on the Web page. In this regard, such significant characterstrings may have a prominent font size, font style (such as bold), orfont effects (such as italicizing and/or underlining), etc. Referring tothe present examples of computers, important attributes/characteristicsof computers such as its speed and capacity are likely to be indicatedby a numeric string followed by phrases such as “Mb RAM”, “MHz”, “Gb”,etc. Because of the use of computation linguistics module 75, productliterature crawler 72 is able to recognize and obtain the phrase andcharacteristic(s) of the phrase, such as its frequency, location, fontsize, font style, font case, font effects, font color, collocation orco-occurrence as product phrase information. Such information can beretained in product phrase database 76 and statistical analysis module78 can then be used provide a ranking of the phrases in any givenproduct category and also stored in product phrase database 76. Inparticular, statistical analysis module 78 will recognize that aparticular phrase was emphasized by the presence of one or morecharacteristic(s) and consequently, provide a higher ranking for theparticular phrase than other phrases that do not have a characteristicassociated with it.

In the preferred embodiment of the illustrated invention, the rankedlisting of the phrases in product phrase database 76 can then be furtheranalyzed by property definition tool 80 to determine whether the phrasesin the product phrase information are in fact relevant productproperties that descriptively characterize the product or productcategory. It should be noted that, preferably, property definition tool80 is executed by a human editor so that common sense judgments can bemade relative to the ranked phrases which were generated utilizing acomputer and statistical analysis module 78. However, a computer orother logic device may be used to automate/semi-automate the function ofproperty definition tool 80.

As can be seen in FIG. 5, the determination of whether the phrases inthe product phrase information are product properties is executed instep 81, preferably by a human editor. If the phrase is determined to benot a relevant product property, the phrase and the product phraseinformation is discarded and the next phrase is analyzed. If the phraseis determined to be a product property (i.e. the phrase descriptivelycharacterizes the product or product category), a determination is madeas to whether the phrase is a numeric character string as shown in step82. For instance, in our example of computers, exemplary numeric phraseswould be the numbers quantifying RAM, hard drive capacity, processorspeed, etc. If the phrase is numeric, a range and interval may beentered if appropriate and recorded for the corresponding numeric phrasein step 84. For instance, relative to RAM, the computer model may beavailable with 32, 64, 96 or 128 Mb of RAM. In this case, the rangewould be 32 to 128 Mb and the interval would be 32 Mb.

Then, a determination is made as to whether the numeric phrase isevaluative as shown in step 86, i.e. the numeric phrase is indicative ofa quality of the product and/or impacts the desirability of the product.As can be readily appreciated, the number associated with RAM isevaluative because the amount of RAM directly impacts the capacity anddesirability of the computer. If the numeric phrase is evaluative, thedirection of evaluation is determined as shown in step 88, i.e. whethera higher value is better or a lower value is better. Again, referring toour example, computers with a higher amount of RAM are more desirablethan computers with less RAM and thus, a higher value is better and thedirection of evaluation is better as the numeric phrase value increases.The direction can be determined manually by a human editor orautomatically via a computer or other device by correlation to price forexample. Of course, in certain product properties that are numeric andevaluative, a lower value may be better. For instance, a lower value inthe weight of a notebook computer would be more desirable than a highervalue. Correspondingly, the direction of evaluation facilitates rankingof each of the phrases as shown in step 89. Thus, the numeric phrase“32” would be ranked lower than “64” etc. at least with respect to theproduct property of RAM. If the numeric phrase is not evaluative, thehuman editor may enter a ranking for the numeric phrase based on his/herproduct knowledge and experience in step 89 and the next phrase may beanalyzed. Of course, because such a numeric phrase is not evaluative,the ranking for the phrase will likely be low as compared to evaluativenumeric phrases.

Referring to the above step 82, if the phrase is not numeric, adetermination is made whether the phrase is discrete in step 83 and theenumerated value names for discrete phrase is entered in step 85. Forinstance, relative to the present example, the phrases “CD-ROM”, “CD-R”and “CD-RW” are all discrete phrases that are also properties of acomputer. It is then determined whether the discrete phrase isevaluative in step 86. As can be appreciated, these discrete phrases areevaluative in that they are indicative of a quality of the productand/or impact the desirability of the product since each of these CDmemory devices provide different level of functionality to the computeras known in the computer arts. In this regard, property definition tool80 then enters the direction of evaluation as shown in step 88 andenters the ranking of the discrete phrases and correspondingly ranks theproducts as shown in step 89. In the present example, the phrases“CD-ROM”, “CD-R” and “CD-RW” are in the order of desirability in acomputer as appreciated in the computer arts. Once again, the order orranking can be determined manually or automatically. Moreover, if thediscrete phrase is not evaluative, then a ranking for the discretephrase is entered in step 89 and the next phrase is analyzed. Of course,because such a discrete phrase is not evaluative, the ranking for thephrase will likely be low as compared to evaluative discrete phrases.

Lastly, if the phrase is neither discrete nor numeric, then the phraseis designated as free-form text as shown in step 87, a ranking isentered as shown in step 89 and the next phrase is analyzed. Suchfree-form text would be relatively rare since the phrase was deemed tobe a product property. In certain products however, such free-form textmay be desirable and add value to the product or undesirable anddiminish the value of the product. For instance, an autograph orinscription on a product may be considered as free-form text which wouldadd value to the product.

In the preferred embodiment of the present invention illustrated in FIG.5, once the analysis as shown in property definition tool 80 iscompleted on the product phrase information stored in product phrasedatabase 76, the resulting product properties (i.e. phrases thatdescriptively characterize the product or product category) are storedin a product property database 90. In addition, by executing propertydefinition tool 80, these product properties that are stored in productproperty database 90 and are also ranked in order of significance in theproduct or product category. Thus, in the above examples of computers,product property database 90 will have a record of product propertiessuch as MHz, Mb RAM, Gb, CD-ROM, CD-R, CD-RW, etc. as well as many otherproduct properties and attributes relevant for evaluating a computer.Moreover, through the execution of property definition tool 80, theseproduct properties are ranked as well. As will be discussed in furtherdetail below, these stored product properties of the product propertydatabase may then be retrieved and used to create catalog 26 for use inevaluating products that are available from various merchants on theirrespective merchant's Web pages to-thereby provide a single shoppinginterface which seamlessly integrates plural on-line merchants to thusfacilitate comparison shopping in an on-line environment.

Of course, it should noted that whereas the above aspects of the presentinvention have been described as applied to computers, the presentinvention is not limited thereto and computers were merely selected asan example of how product literature crawler 72 and property definitiontool 80 may be used. In this regard, it should be appreciated that thepresent invention may be applied to all different products and servicesthat can be effectively marketed on a networked environment such asInternet 100. Thus, the present invention may be applied to all goods aswell as many services including insurance, financial services, rentals,lodging, transportation, vacation packages, etc. in a manner similar tothat discussed above.

FIG. 6 shows a block diagram of a method in accordance with thepreferred embodiment of the present invention for validating the productofferings of on-line merchants and for creating a new product recordbased on product properties. As can be appreciated, the lower portion ofFIG. 6 provides an abbreviated illustration of FIG. 5 which wasdiscussed in detail above which primarily explained the method fordetermining product properties as gathered from manufacturer's productspecification Web pages 46 and other sources by product literaturecrawler 72. In a similar manner, product phrase information may begathered from the merchant's information source such as the merchant'sWeb page 42 by product offerings crawler 74 which may also be generatedby shopping server 20. Thus, like product literature crawler 72, productofferings crawler 74 gathers product phrase information from merchant'sWeb page 42 including a phrase and at least one characteristic of thephrase utilizing computational linguistics module (not shown). Again,the characteristic of the phrase may be its frequency, location, fontsize, font style, font case, font effects, and font color of the phrasein the Web page as well as the frequency of collocation andco-occurrence of phrases.

In addition, because each merchant will likely offer various models ofmore than one manufacturer, product offerings crawler 74 also obtainsinformation regarding product model and manufacturer's identity.Moreover, because each of the products may be purchased through aparticular merchant at a specified price as designated by the particularmerchant, merchant identity information such as the merchant's URL, andprice information for each of the offered products are also gathered byproduct offerings crawler 74 so that information regarding the product,price, and the identity of the merchant offering the product at a givenprice are all correlated to one another. All of the above describedgathered information is stored into product offerings database 92. Thedetails of how the manufacturer's identity, product model, productphrase information, merchant identity information and the pricinginformation are all gathered is substantially similar to the methoddescribed above relative product literature crawler 72 of FIG. 5 andthus, are omitted here to avoid repetition. However, based on theteachings above, it should be clear to a person skilled in the art howsuch information can be gathered utilizing product offerings crawler 74and be saved in product offerings database 92 and used to create productcatalog 26.

Thus, in correspondence with the computer example used above, productsofferings crawler 74 may visit various Web pages of computer merchantsto gather all the required information regarding every make and model ofcomputers offered in computer merchant's Web page 42 as well as themerchant identity information such as the merchant's relevant URL. Thisinformation is stored in product offerings database 92 in a uniformformat for further processing.

In accordance with the preferred embodiment of the present method asshown in FIG. 6, once the above noted information is gathered and storedin product offerings database 92, it is validated using validation tool93 to match the various merchant offerings to the product informationstored in products catalog 26 in shopping server 20 shown in FIG. 1. Asdescribed previously, the products catalog 26 on shopping server 20stores product information such as product descriptions, pricing, andother product information for plural merchants which may be culled frommerchant servers 40 using automated product offerings crawler 74.Shopping server 20 accesses and presents the product information storedin products catalog 26 to client computer 12 to thereby provide a singleshopping interface with seamlessly integrated plural on-line merchantsto thereby facilitate comparison shopping in an on-line environment.

For each given product offering in product offerings database 92,products catalog 26 is searched to determine if there is a correspondingmatch present in products catalog 26 as shown in step 94. If there issuch a match, the validation is deemed to be completed for theparticular product offering and another product offering in productofferings catalog 92 is selected for validation via validation tool 93.It should be noted that validation tool 93 may preferably be executed bya human editor who accesses via a computer or other means, productcatalog 26. However, validation tool 93 may also be executed by acomputer or other automated device.

If however, a corresponding match in products catalog 26 is not found,product record creation tool 95 may be executed to update productscatalog 26 with the new product offering found in product offeringsdatabase 92. In this regard, product property database 90 as describedpreviously is accessed to provide the ranked product properties of aproduct or product category to product record creation tool 95. Theseranked product properties which were obtained via product literaturecrawler 72 can be then used to create a record on products catalog 26for the new product offering found in product offerings database 92thereby ensuring the obtaining of the important product properties forthe new product offering. It is again noted that the product recordcreation tool 95 may preferably be executed by a human editor. However,product record creation tool 95 may be executed by a computer or otherautomated device.

Correspondingly, referring again to the computer example, the rankedproduct properties which were processed via product definition tool 80and stored in product property database 90 can be provided to productrecord creation tool 95 so that all of the important product propertiesfor the new product offering are obtained and entered into productcatalog 26 when a new record is created. These product properties willinclude MHz, Mb RAM, Gb, CD-ROM, CD-R, CD-RW, etc. as well as many otherproduct properties and attributes stored in the product propertydatabase 90 which are relevant for evaluating a computer. Of course,again, it is noted that application to computer sales were merelyselected as an example and that the present invention may be applied toall different products and services that can be effectively marketed ona networked environment such as the Internet 100.

Thus, in this manner, the present invention also allows new productofferings available in the marketplace to be easily integrated into theproducts catalog 26 thereby periodically updating products catalog 26 toensure accurate offering of newest products and prices to clientcomputer 12. However, as can now be appreciated, because the updating isattained via product offerings crawler 74, the product information isnot updated in real time, but rather periodically in the background ofshopping server 20. The product information on products catalog 26 canbe used to display products available for purchase by product type, partnumbers, price, keywords, or product features in any desirable mannerusing an interface of shopping server 20 as described previously. Theproduct information can be displayed side by side in the browser windowof client computer 12 to permit the shopper to comparison shop andchoose products from any one or more of merchant servers 40 based on theproduct information. Once the shopper has selected all desired productsand options from all desired merchants, the shopper can complete theshopping and “check out” as described previously by confirming the orderwhich verifies pricing information, shipping information, and otherdetails of the desired purchase.

It is again noted that in the above described embodiment, propertydefinition tool 80, validation tool 93 and product record creation tool95 are preferably executed by a human editor utilizing a computer orother device so that their execution is semi-automatic. Because of thepresent invention provides these distinct tools with distinct functions,human editors having different skills and knowledge can be utilized foreach of the tools. For instance, it takes a relatively lower level ofskill and knowledge to execute validation tool 93 and product recordcreation tool 95, whereas it takes a higher degree of skill andknowledge to execute property definition tool 80. Therefore, thisembodiment allows efficient human resource management since the toolsand their respective functions are preferably separated and moreexperienced human editors can be assigned to execute property definitiontool 80 and the less experienced human editors can be assigned toexecute the other tools. Of course, it should also be appreciated thatin alternative embodiments, the above noted tools may be combined inpart or in total and can also be executed automatically via computer orother device so that use of human editors is not necessary.

Another embodiment of the invention is illustrated in FIG. 8. Theembodiment of FIG. 8 includes a property definition tool that is adaptedto aggregate product information from plural sources, such as merchantservers 40 and manufacturers servers 44, to produce a product catalog 26in a highly automated manner. Property definition tool 800 can be in theform of software running on a general purpose computer, such as shoppingserver 20 in the embodiment of FIG. 8. Property definition tool 800includes clusterer module 802, categorizer module 804, nameselector/cleanser module 806, image selector module 808, propertyscraper module 810, supplemental keyword generator module 812, propertyaggregator module 814, description generator module 816, allied productsdiscovery module 818, and post-processing module 820.

FIG. 9 illustrates a flowchart of the high level function of propertydefinition tool 800 of preferred embodiment. Each step of FIG. 9 will bedescribed in greater detail below. In step 900, clusterer module 802analyzes merchant offerings from plural product information records,such as records stored on merchant servers 40, and clusters, i.e.,groups, them according to which are most likely to be the same product,and assigns or creates a UPID (Universal Product ID) for each. Ofcourse, the product information can be gathered from product informationrecords using a crawler, such as literature crawler 72 described above.In this embodiment, the crawler can retrieve product information recordsin their entirety for automatic processing by property definition tool800.

In step 902, categorizer module 804 places each UPID into a category ina product catalog taxonomy based on a comparative analysis of thatproduct with other products already classified in categories of thetaxonomy. The determination of product catalog taxonomies is generallywell known. In step 904, name selector/cleanser module 806 selects thebest among multiple variant names for the product found in the productrecords of a group, and then cleanses the name of any superfluousinserted or concatenated text that is commonly found in the name fieldof products. It also then builds an optional, longer name that is of aconsistent style and has only the most relevant content for the specificcategory in question.

In step 906, image selector module 808 chooses the most preferableproduct image from all various product information records in a group,based on size, type, quality, proportion, reliability of source, andother factors. In step 908, property scraper module 810 scrapesnormalized attributes values for each product from every availableproduct information record and supplies confidence ratings to every actof scraping that it performs. In step 910, supplemental keywordgenerator module 812 repeats a process similar to that of step 908, butwith reference to open-ended keywords for each group, rather than fornormalized attributes.

In step 912, property aggregator module processes the output of propertyscraper module 810 by employing a weighted voting engine to merge themany scrapings and determine a final value for each attribute of eachproduct. Also, in step 810, the supplemental keywords are normalizedbased on one of various algorithms.

In step 914, description generator 816 composes short texts describingeach product. Such texts are non-evaluative and are based on templatesusing the attribute values attained in steps 810 and 812. For example,this can be accomplished by randomly selecting one of a number ofdescription templates that can be instantiated by reference to the mostimportant properties of the product, and then executing minor word orphrase variation to avoid monotony. A final step ensures proper sentenceformatting, punctuation, and capitalization.

In step 916, allied products module 818 recognizes related alliedproducts, such as accessories, parts, connectors, etc., and the bundlesor kits that can be comprised of a set of allied products. Any itemsfalling below confidence thresholds, can be handled specially, eithermanually or automatically, in various ways. Allied products module 818is described in greater detail below.

Clustering, accomplished by clusterer module 802, is the process ofgrouping together various merchant offerings, which have noready-to-hand UPID, and creating a new UPID for each group. This processresults in a one-product-to-many-prices relationship. Numerous featurescan be extracted from merchant offer records, manufacturer records,distributor records, and other records describing products (collectivelyreferred to as “product information records” herein) in order to enableclustering.

Clustering can be run per manufacturer, i.e., the “primary key” of theprocess can be the manufacturer name. Thus the first problem to besolved is determining that different forms of reference to the samemanufacturer are indeed the same. The risk of accidentally clusteringproducts of different manufacturers is slight, but when it does happen,it can be a very critical error, and therefore it is important for thesystem to avoid this error. The system does so largely by discoveringpatterns in manufacturer part numbers and model identifiers. Note thatthis presumes that the manufacturer is already separated out of theproduct name, which is not always the case—some product informationrecords include the manufacturer or brand name as part of the productname field. Hence, a first pass may be required to populate themanufacturer name field for use in clustering.

Once the manufacturer (or brand) name is discretely obtained, clusterermodule 802 is given this name as a data string that it uses in asub-string search in order to select all product information recordswhere the manufacturer name begins with this sub-string. For example,clusterer module 802 may be started over the space of product offeringswith manufacturer names starting with “bell”. This will define the dataset for the process as selected product offerings with manufacturerstrings such as “Bell Atlantic”, “Bell Industries, Inc.”, “and BellMicroproducts”. These names are normalized (removal of irrelevant partssuch as “Inc.” and “Corp.”), and further words are removed from the enduntil the minimum manufacturer name is found from the catalog thatmatches one manufacturer name from the catalog. As an example, there canbe plural different names among data providers today that are all waysof saying “Sony,” and thus it requires more work in order to decidewhich of the plural “Sony-like” manufacturer names should be used as“canonical”. The system may use any manufacturer aliases from thevarious data sources, and in addition, aliases may be inferred as thecatalog is “bootstrapped” and products are created and merchantofferings are mapped to the new products, either manually or through UPCmatches (which don't require manufacturer name merchants).

After defining a data set for a particular pass, clusterer module 804begins the clustering step. There are a number of well known standard AI“clustering” algorithms, any one of which could suffice for the baselineclustering. However, successful clustering of products often requiresaugmenting the baseline clustering with numerous elements andadjustments as explained below. A simple outline of a baselineclustering procedure would be as follows:

a. If there are not yet any clusters, i.e. product groups, then thefirst product becomes the first cluster

b. Otherwise, search through the clusters for a close fit

c. If there is a close fit, combine it

d. If there is no close fit, it becomes its own cluster

There are several approaches for determining “close fit”. The followingsections explain examples of such approaches. The first approach indetermining what products are the same, i.e. should be in the samegroup, is examining manufacturer part numbers, if available, or UPC ormodel IDs, and normalizing superficial variations in their nomenclature.In so doing, clusterer module 802 makes several passes, and may mergetogether what were initially separate clusters, as it narrows down thepossibilities. This narrowing down is in many cases a virtue of clustermodule 802 “teaching itself” what the letter-number patterns appear tobe, inductively, in various product families around the industry, andusing this knowledge to rule out bad data. Indeed, clusterer module 802operates differently in many respects because of the fact that bad datais common, as opposed to how it could work in an ideal world where alldata sources were pristine.

An example is that one manufacturer may give a part number to all of itsvideo camcorders that starts with the letters “VCM” followed by one moreletters, and then three numbers. However, some merchants errantly inserttheir internal SKU into the manufacturer part number filed (in fact avery common problem). Because the internal SKU of the merchant does notfit the number-letter pattern above, and in fact is very far from it,the system programmed to look for part numbers in the anticipated formatwould assume that the string having the internal SKU is an error, andproceed to examine other parts of the record where some other data mightbe found to enable the clustering of the offer in question (for example,despite the bad manufacturer part number, the product name might be inperfect shape, and a perfect match with many other offerings in thedatabase).

Clusterer module 802 should also be able to adapt the numerous waysmerchants have of modifying the UPC of a product (few of them leave itas is). Some remove a leading zero, or add a digit or two on the endthat has their own internal meaning, or remove the checksum digits.Through automated trial-and-error, clusterer module 802 attempts tode-construct and re-construct a particular merchant's pattern oftweaking the UPCs. This is made possible by having at least one sourcewhere the definite and complete UPC is known, and then applying numerousknown heuristic techniques, to see which transformation rules willsuccessfully reproduce the definitive UPC, from the merchant'sidiosyncratic UPC (this can be done using Hidden Markov Models, forexample, or using just standard logic programming). A hidden Markovmodel (HMM) is a well known variant of a finite state machine having aset of states, Q, an output alphabet, 0, transition probabilities, A,output probabilities, B, and initial state probabilities, Pi. Thecurrent state is not observable. Instead, each state produces an outputwith a certain probability, B. Usually the states, Q, and outputs, O,are understood, so an HMM is said to be a triple, (A, B, Pi). HMMs areknown for use in speech recognition and other applications.

There are many other functions of clusterer module 802 that arediscussed below. After clustering is complete in step 900 of FIG. 8,auto-validation can be performed wherein additional merchant offers thatappear over a period of weeks and months, can be matched using the samemethods generally as the original clustering in step 900.

When present, a model ID or product name is often the best clue towhether items in separate product description records are the same, andthus should be clustered together in the same group by clusterer module802. However there are many ways in which this can fail, which need tobe accounted for. The first is merely punctuation and capitalization,such as the difference between:

“$69.49 Sony MD-74 Mini-Disc player”

“$75.99 SONY MD74”

“$68.00 Sony MD 74 Mini Disc Personal Player”

Another is that the Model ID may be concatenated together withextraneous terms such as:

“$59.99 Sony Black MD 74”

“$68.99 Sony Silver MD-74 BB”

Where ‘BB’ stands for “Bass Boost” and is simply a feature that all suchmodels possess and does not truly indicate its being a differentproduct. By contrast, the difference between black and silver doesindicate a significant difference as many persons who are shopping for asilver model would not want to have a black one, and in some casesmerchants may even charge more for one color than for another of what isotherwise the identical device.

While only elementary logic is required in order to handle and resolvedifference in punctuation, special handling must obtain for items suchas color, size, and extra features of the product, or even kits such as:

“$99.50 Special! Sony MD-74 Premium Kit with Mini Speakers and LeatherCase”

In this case, the difference in price; the presence of “kit”; themention of items which the product database shows to be separatecategories of products in and of themselves (speakers, case), are allclues that there is a high probability of this offer being a “bundle” ofproducts that includes the MD-74, and is not merely the MD-74 by itself.

In many cases a fuzzy string match can provide some clue as to whetheroffers might be the same, and is critical in taking care of spellingerrors in the source data, e.g.:

“$74.50 Sony Mini-Disc Player MD-74”

“$69.49 Sony Mini-Discc [sic] Player MD74”

As a first pass, fuzzy match on the entire string can easily round up afirst batch of candidates for clustering. For example the following listmight be chosen from countless thousands of offerings as an initialcluster, on fuzzy match alone:

“Sony MD-80 Mini-Disc Player”

“Mini-Disc Player MD-74 from Sony”

“Sony New MD-74 music disc player”

“M-740 Symphony Synth from Moog”

“Sony MD-74 Personal Music Device”

“Sony 8-inch Mini-TV-80”

Note that all these have a significant overlapping portion of textcontent. Note however that “Symphony” and “Sony” have a 67% fuzzymatch—8 of the 12 characters in both words combined, are the same and inthe same order. This shows how inevitable it is that some fuzzy matchcandidates are still going to be wrong. Nonetheless, that cluster module802 has only 6 products to process, not 600,000, is an immensely greatnarrowing down. What remains is to identify the difference between MD-74and MD-80 as being significant in order to separate the first item inthe list above from the rest of items in the list; and then to determinethat the presence of “Synth” (or “Moog”) and “TV” invalidate the 4th and6th items respectively.

Clusterer module 802 should also ignore certain words. Note in theforegoing example the words “New” and “Player” do not really addanything. “New” is an example of an exceptional word that is so oftenused in the marketing of all kinds of products, that it must be handledseparately from the way a random word is handled. Specifically it needsto be ignored for all purposes except separating new from used or refurbproducts. “Player” on the other hand is helpful in an early pass todevelop an initial cluster; however the system must not assign such agreat importance to it that the presence vs. non-presence of this singleshall count as a different product. This can be well grounded in thefact that “player is a “generic noun” to refer to an entire category ofproducts. Other examples are “TV”, “CD”, “Video”, and the like. Inparticularly late stages of clustering step 900, generic nouns can beignored, because it is simply optional whether marketers include them ornot, in product names. This does not take away from the fact that theyare important clues in making a first pass at what should be included inthe initial cluster.

Numbers such as the “74” and “80” in “MD-74” and “MD-80” can obviouslybe critical to separating two models of products from one another. As ageneral rule, there being a different number in a model name or productname should be taken to indicate that it is a different product.However, there need to be exceptions to this as well, for example:

“$12.99 Hasbro Wayne Gretzky #13 Action Figure”

“$13.99 Hasbro Wayne Gretzky 6-inch action Figure Mighty Ducks”

Here the difference between “13” and “6” could make clusterer module 802assume these are different products, when in fact they are the same. Thebest way to resolve this is for the system to know which attribute for aparticular category might be expressed in numbers and also might beconcatenated as part of the product name. In this case, sports actionfigures have jersey numbers as a possible attribute (“#13”) and theyalso have a height in inches (“6-inch”). By having the system check forthese parameters, it can be prevented from assigning a drastically lowerprobability of match, merely due to the appearance of different numberswithin the product name string. In the absence of finding suchparameters, the system would lower the probability estimation of theproducts being a match, whenever there are differing numbers presentwithin the product name.

This is notwithstanding that additional numbers in the names can stillrule out the clustering, such as the difference between the “3” and “4”in the following:

“$13.99 Hasbro Wayne Gretzky #13 Action Figure Series 3”

“$14.99 Hasbro Wayne Gretzky 6-inch action Figure Mighty Ducks Series 4”

In determining which names are more likely to be significant forseparating clusters, i.e., forming groups of items corresponding to aspecific product, a differential frequency analysis can be performedbetween merchants that are specialized on certain categories, andmerchants that broadly cover many categories; similarly, betweenofferings already catalogued in a certain category, and the entirecatalog. The result of this analysis is a list of terms, for eachcategory, that are very much more frequent in that category thangenerally in the entire corpus. This is useful in categorization of newitems (discussed later) but also for clustering, as words (or phrases)that are very common within one category, are usually ones that thesystem can look upon as not indicating a difference between products inthat category. Take for example the word “saber.” This will be aninfrequently mentioned word in the entire corpus, but very frequentlymentioned in action figures, given the predominance of Star Wars actionfigures that “come with a light saber.” Now suppose the system sees twoofferings as follows:

“$5.99 Obi Wan Kenobi 6” Nabo garb with light saber”

“$5.99 Obi Wan Kenobi 6” Naboo garb”

Ordinarily, the presence of “saber” in one but not the other, wouldweigh rather heavily toward counting the items as different, however,the system's recognizing how common it is for “saber” to be mentioned inthis category, raises the likelihood that the word is merely an optionaldescriptive phrase, and not special to one action figure versus another.Again, this is probabilistic and merely one of many factors that can beassessed.

Another pragmatic check which can help the system in clustering step900, is checking prior probability e.g., examining how many stronglysimilar products are in the marketplace, as evidenced by the content ofthe available product information records or other information. If thenumber is high, then the system should be suspicious even of minordifferences in product names. However if the number is low, the systemcan be more tolerant of minor variations. For example, if there are onlyone or two “Abraham Lincoln action figure” products in the database,then the probability of an offering constituting an additional productare relatively slim. By contrast, seeing that there are over 100different “Luke Skywalker action figure” products in the database,suggests that a new Luke Skywalker offering with minor differences inthe name, might very well be a new and different model. In other words,the odds of a Luke Skywalker action figure being wrongly clustered,initially, are very great—there is only a 1-in-100 chance that itbelongs to any given group. Meanwhile if there are only 2 Abe Lincolnaction figures, then there is immediately a 50-50 chance of an offeringbelonging to on or the other cluster. This can factor into theconfidence of any clustering calculation.

In determining the number of groups, the merchant coverage may beconsidered, such that (1) the largest selection of similar items offeredby a single merchant serves as a minimum number of groups for thatfamily of items and (2) the diversity of product coverage of variousmerchants can be extrapolated to provide a further clue as to thecorrect number of groups. For example if the system is addressing manyhundreds of offerings that look something like “Luke Skywalker ActionFigure” then, supposing one merchant along offers 37 different “LukeSkywalkers,” the system can presume (on faith that this one particularmerchant does not duplicate too many offers in its data set) that atleast 37 clusters are needed for this family of products. Furthermore ifthere are, among products already UPIDized, approximately 1.5 uniqueofferings per every 10 offerings altogether (meaning, for example thatKB Kids might have 23 such action figures where 3 of the 23 are uniquein being offered by KB Kids only, and that this sort of ratio is theaverage such ratio found among all merchants whose Luke Skywalker actionfigures have already been UPIDized), then the system can use thisinformation in order to extrapolate (over the remaining set of merchantswhich have not yet had their offerings of such products UPIDized) as tohow many estimated new unique products might be present, assuming thesame historical diversity ratio obtains. All these measures areeffectively “pragmatic” or “heuristic” measures which can be implementedas weights upon the confidence level of various tentative clusteringcombinations—a combination which accords well with the aforementionedmeasures (i.e. falls close to extrapolated figures) will have a higherconfidence level than one which departs widely from such measures.

In many cases where names, descriptions, and specs make it hard to forclusterer module 802 to determine whether two products are the same, theprices themselves are an important, and possibly decisive, factor. Forexample if one offering is $7.99 and the other is $59.99, then, despitesuperficially similar descriptions, they are very unlikely to be thesame product. However there are several caveats. First, the clusterermust be careful to parse and analyze for any exceptional circumstances,such as close-outs or clearance sales, refurbished items, andrecertified items (such as returned products in an opened box). In somecases, these items can be much lower in cost.

Another difference that must be factored in is the typical differentialin merchant pricing. Many first-tier merchants charge, routinely, up to30% or even more than some discount merchants. Another consideration isthe price competitiveness and consistency in the category. In somecategories, the system can determined from items already catalogued,that the price fluctuation among merchants is typically greater thanthat of other categories. If, after taking all these factors intoconsideration, the price difference is still very great, then thelikelihood of the offerings being of the same product, is loweredaccordingly.

Aside from merchant pricing, most merchants also list the MSRP of aproduct—usually to boast the apparent “savings” derived as thedifference of the merchant price and the MSRP. Since merchants usuallyadopt the same MSRP from a manufacturer or distributor, merchants willtend to be the same as each other in what they construe to be the MSRP,even more so than in the actual merchant prices themselves. So when thisinformation is available, it can also be weighed in by clusterer module802, in fact, even more heavily than is the similar of merchant pricing.Like many other factors, it should not be merely a Boolean test, but aweight, because sometimes the data will be faulty (e.g. through amerchant's typo or merely through one merchant having an out-of-dateMSRP while another merchant reflects the more up-to-date MSRP).

The dilemma in finding these parameters is that clustering ideally takesplace prior to categorization. This requires a tentative guess as to thecategorization of the product, despite that categorization is not finaluntil the clustering is final. Thus a dialectical or iterative processflow between the algorithms of clusterer module 802 and categorizermodule 804 is sometimes desirable or even inevitable. Clusterer module802 might revise the cluster membership in light of a tentativecategorization, but following this, the categorization must be checkedagain, in which case categorizer module 804 might revise its category“guess” as a result of the cluster having changed. This iterativeprocessing must continue until both the result of clustering step 900and categorization step 902 have stabilized and both have surpassedtheir required confidence thresholds. The combination of both theiroutputs with the highest minimum confidence score between both clusterermodule 802 and categorizer module 804 will prevail. In other words ifclusterer module 802 has cluster C1 or C2 and categorizer module 804 isoutputting category A or B, the following matrix of outcomes couldresult:

C1- C2- A-  0.74/0.32* 0.68/0.82 B- 0.73/0.71 0.68/0.74 *Clusteringconfidence/Categorization confidence

Assuming a confidence threshold for both clusterer module 802 andcategorizer module 804 of 0.70, the system would go with cluster C1 andcategory B, 34 as the minimum confidence in that scenario is 0.71—betterthan in any other scenario, and above thresholds for both. Of course,other algorithms can be used to correlate the results of clusterermodule 802 and categorizer module 804.

Generally the system assumes that, the more words that are different intwo product names, the less likely they are to be the same product.However the system needs to be able to construe synonyms, hyponyms, andhypernyms in an intelligent manner. For example, consider:

“Sony MD-74 mini-disc player”

“Sony Inc., MD-74 music listening device”

On the surface, there seem to be more words that are different, than arethe same. However, “player” is a hyponym of “device” (conversely,“device” is a hypernym of “player”). Meanwhile “Sony” and “Sony Inc”would be treated as synonyms. These words can be assigned partial-creditfor a match. These facts, in combination with the matching model number,are likely to be sufficient for cluster module 802 to confidentlycluster these offerings.

Further, a product often comes in two or more variants. For example atoaster oven may come in black and white, and its model ID might be anyone of the following:

“PG-400-B” [where B signifies Black]

“PG-400-W” [where W signifies “white]

“PG-400” [where text description following mentions black or white orboth]

Other examples are right/left-handed golf clubs, etc. These can show upas something similar to:

“Titleist Pro 700 Driver R”

“Titleist pro 700 Driver L”

Generally these variants, though somewhat superficial from some pointsof view, are nonetheless separate and individual part numbers from themanufacturer, and are of no small significance to certain shoppers.Therefore they are given unique product IDs. They can however be relatedas part of a single product line or as configuration variants of a basicmodel (e.g. when the right-handed golf club is considered the basicmodel the left-handed is a variant, or when the black toaster oven isconsidered the basic model, the almond colored one is considered avariant, etc.).

Whether products should be, in any sense, clustered, is partly a matterof the purpose-at-hand. While generally clustering refers to theassigning a single-model, i.e. product, to its various price offeringsby grouping together product information records corresponding to theproduct. However, there are meaningful configuration variants that,while technically counting as different models, are often thought byconsumers and even retailers as being “essentially” the same model, butjust in varying styles, etc. Likewise, product models can be part of aseries, and multiple product series can be part of a product family,etc. Clusterer module 802 therefore can provide plural levels ofsuper-clustering and/or sub-clustering. One among many possible semanticlabeling schemata for these levels is as follows:

(1) Product Line

(2) Product Family

(3) Product Series

(4) Model*

(5) Configuration of model

The asterisk (*) indicates the baseline clustering performed byclusterer module 802 at the level of merchant offers, can occurprocedurally before any super-clustering (levels 1-3) and sub-clustering(level 5). An example of all five levels would be the Fujistu LifebookP-2040 with 384 MB RAM. The Fujitsu brand has the “Lifebook” productline, in which is the “P” family of notebook computers (as opposed tothe “S” family), within which is the “2000” series (as opposed to the1000 series), within which is the “2040” model (as opposed to the 2080and 2100 models), and which can optionally come, brand new, with 384 MBRAM (as opposed to having 256 or 512 MB RAM).

The same fundamental methods of clustering are used at any levels,merely with a different set of differences in naming and specificationsthat either are or are not considered to be significant for the level inquestion.

Categorization step 902 includes the process of assigning each UPID to aproper category within taxonomy 700. This can be accomplished chiefly bytwo processes. First, the attributes and attribute value sets definedfor each category, in a known manner along with their aliases, synonyms,hypernyms, etc. can be examined. Second, actual product informationrecords already classified in each category can be examined. Any numberof AI machine-learning algorithms can be used for the classificationincluding but not limited to: case-based reasoning, genetic algorithms,neural nets, etc. What is importation is the feature extraction thatprecedes the invocation of the machine learning module, and not so muchwhich particular kind of machine-learning module is used.

In the feature extraction process of categorization step 902, eachmatching item that is found in the product information records, whetheran attribute name, value, unit of measure; a brand name; keywords andphrases found in product descriptions, etc. counts in favor of theproduct being in that category. Conversely, items found that seem toconflict, bring about major deductions in probability scores. Ultimatelya final score is reached for each UPID against each category. The hopeis that a confidence threshold will be surpassed on one and only oneleaf-node category. In the minority of cases where this result does notobtain, a manual (or other external) validation is can be used, or thecategorization can be deferred.

Usually for marketing reasons, resellers produce very long, very “ugly”names for their products. This is especially true in the online worldwhere resellers are trying to please the search engines' web crawlers asmuch as they are human beings—meaning they want to include everyconceivable relevant piece of text in the product name.

Otherwise, they are afraid, they might not get the search resultsranking on Google or Yahoo! Search that they are hoping for. The resultis that a ideal product name such as:

-   -   “Sony MD-74 Mini-Disc Player”    -   is often listed in a product record as:    -   “New Sony MD-74 (MD74, MD 74) Mini-Disc Player Personal Music        Listening Device with Rebate and Free Leather Case Now For Grads        and Dads”

Fortunately, not all names are this long and extraneous in nature.However, name cleansing step 904 is still required in many cases. Thefirst obvious step in determining an attractive name screen to be usedfor the UPID product record, is to eliminate those that are very long,in favor of those that are not.

The other kind of undesirable name is that which tries to over-load thename field as a mini-product-spec table, all in on, such as:

“Sony MD-74 23-hr battery, 6 watt output, headphones, 8 oz”

“Consider this along with:

“Sony Corp. MD-74 Mini-Disc Personal Music Listening Device”

Here the length of the name alone does not help since both are nearlythe same length, yet the latter is greatly preferred over the former forcataloging purposes. By noting that the former contains many attributenames and attribute value strings from the product record, we can assign“de-merits” to that name, i.e. make it less likely to be selected as theproduct name by name selector/cleanser module 806.

Also, marketer have a habit of overloading the name field of productinformation records to carry many other elements of information besidesthe name of product. There is virtually no limit to this in terms ofvocabulary. However certain linguistic cues can be semantically relatedto marketing, either through a manual list or through statisticalaccounting of which words are more commonly included in the marketing“fluff” that clutters product names. The statistical approach isattractive in that is more automated. This procedure requires somesample data to have been tagged as having “marketing language” in thenames, together with a contrasting set of data that shows the sameproduct names without the marketing language. A differential analysis,with word/phrase frequency, word contiguity, and other standardstatistical NLP methods can be applied to determine a good probabilisticprofile of what constitutes marketing language for each category ofproduct.

Once name selector/cleanser 806 has narrowed down possible names to asimple, concise, clean product name, it is also desirable to generate anoptional longer name that is canonical. Canonical means that it followsa consistent form across categories, which is to mention only (a) themost important variant configuration elements (such as color,right-handed) and (b) the most important attributes (such as theresolution of a digital camera). Having a reliable, consistent style oflong name lets those who utilize the catalog enjoy maximum flexibilityin surfacing a short name, or a long name, as best fits theirapplications.

In step 906, image selector module 808 chooses the most preferable imagefrom all various sources, based on size, type, quality, proportion,reliability of source, etc. Various rules and thresholds can be used toselect the most preferable image. For example, the image may have to beof a certain minimum resolution and size. Alternatively, image selectormodule 808 can be programmed to use the image from product informationrecords from a list of preferred sources (e.g. merchant servers 40) inorder of availability.

In step 908, property scraper module 810 parses and analyzes the productinformation records, such as web pages or PDF documents form a sourcesuch as a merchant, manufacturer, distributor, reviewer, or the like, toextract the product spec information from that source in a normalizedform. Property scraper module 810 can then discard or leave the text ofthe product information record in question.

Property scraping step 908 can be accomplished as follows. First DOM(Document object modeling) can be accomplished to separate the mainproduct spec portion of the page from any cross-sell or up-sellmerchandise, and from any linked accessories, etc. Next, differentsentence, phrase and table structures can be parsed to spot individualspecs on the page one at a time. Negation and other functions can behandled separately so that property scraper module 810 does notmistakenly construe these as being built-in to the product. Resolving ofsynonyms and aliases to normalize the jargon used among various productinformation records for both the attribute names and the values can alsobe accomplished. Bonus keywords or specs that do not fit pre-definedspecs for the category of product in question, including a gathering ofany novel specs that would otherwise “fall between the cracks” can beretrieved. A confidence level can be assigned to each act of scraping,based on things like whether the attribute name and value were bothfound, or just the value string was found; or based on whether theresome extraneous words found in between the attribute name and value, orwhether there were line breaks or adjacent cells in a table (all ofthese items introduce some risk that the spec is somehow modified,qualified, or disclaimerized and therefore might possibly not be exactlythe spec which it appears to be). Also, the scraper may pick upconflicting information on the page (e.g. they sell one size, but laterexplain it is available in many), so this lowers the confidence, andhigher confidence is given to the text that seems more likely to becorrect (i.e. the one that is more closely collocated with the otherspecs on the page). The weighted combination of all these methodsresults is a confidence score for each individual spec value from eachproduct information record that is scraped.

It is often important for the system to perform recognition andconversion of units of measure to a standard for each spec, handlingboth synonyms, e.g. “lbs.” to “lb.”, and conversion, e.g. “2.2 lb.” to“1 kg”. In the event that the attribute name cannot be found, the unitscan sometimes reliably identify a correct value (e.g. 3.1 megapixelcamera does not need the word “resolution” in order to deduce that “3.1megapixel” is the resolution, due to the uniqueness of the “megapixel”unit withing that category). Numbers must be parsed in all variouslyexpressed styles, including fractions, Roman numerals, and thoseformatted with commas. Numeric ranges need to be recognized both as apossibility in the attribute setup, i.e. having a composite attributecomposed of “min” and “max” atomic attributes. Different types ofverbiage may indicate a range, such as a comma separated list of values(e.g. for 1, 2, or 3 players), a hyphenated min-max range, etc.

Textual-type attributes may have different rules. In specs, aBoolean-type attribute (no/yes) will require the attribute name to bepresent, and not require the word “yes.” Correctly determining the “no”value is a bit more tricky, as it requires the system to look for othernegating language, usually other than a simple “no” (e.g. “optional” or“not included”).

In other cases, particularly with attributes that allow multiple values,or where the language of the values themselves is distinct enough not torequire qualification by inclusion of the attribute within the productname field or within a definite description in the product text, e.g.“This HDTV television . . . ” clearly indicates to the reader that“HDTV” refers to the “Compatibility” attribute.

The source document from a particular product information record isoften HTML, XML, PDF or another tag-laden document type. This is both abenefit and a detriment to property scraper module 810, in that thesetags can both indicate and obscure the specs that are being sought.Therefore, multiple passes (utilizing different methods of handling thetags) can be used, as explained below.

One method is to simply ignore the tags by parsing them out. Thismethod, simple though it may be, actually yields a great deal of specs.For example, if an action figure product page on a website reads“Height: 6-inch” it may read, in the HTML sources as “Height: <TC><Font: Helvetica> </B> <I>6 inches”. In other words, there areintervening tags whose purpose is to align the information within atable, change the font from one column to the next, etc. By merelytossing out the tags within one row of the table (while keeping theinformation that it is within a single row), the scraper sees “Height:6”, and suddenly the spec is very near to being scrapable.

However in many other cases, the tagging must be parsed and analyzed,rather than merely discarded, in order to yield the desired result. Takethe same example as above, where on the row above we might have

“Phantom Series 4”

and on the row below have

“vehicle included”.

By maintaining or parsing the row-delineation tags, property scrapermodule 810 knows that “Phantom Series 4” is one row, and “Height: 6” isone row, and “vehicle included” is another. If all the tags wereignored, then property scraper module 810 would lose this rowdelimiting, and would have the continuous string:

“Phantom Series 4” Height: 6 vehicle included”

This would be harder to parse and analyze, and there is probably somerisk that the system might think the action figure is 4 inches in heightand comes with a 6-inch vehicle! Thus it is critical to actually parsethe tags and thereby maintain the document structure.

There are a myriad of other ways in which the tagging is informative.Another case is where the system is trying to determine where the listof specs ends, in a block of text. Often the Product Information Recordwill, for example, switch fonts or text style or paragraph indentationwhen the specs are coming to an end and when a list of cross-sellproducts is about to begin. It is vital that this transition be noted sothat the cross-sell products are not accidentally construed as featuresof the main product itself (e.g. construing a memory card that is anoptional accessory for a digital camera, as something that comes withthe camera).

Many product information records produce tables that do not,unfortunately, put the attribute name and value close to each other atall. An example is the following:

Pick the P-2000 Series Configuration That is Right For You!

Fujitsu P-Series Model RAM Wi-Fi Included OS Price P-2040 256 No XP Home$1249 P-2080 384 No XP Home $1399 P-2100 512 Yes XP Pro $1549In this example, multiple variant models are listed together in a singletable, and the header row must be parsed and one column at a time mustbe scraped, in order to gather the specs correctly for each model.

Some tables found in product information records are even morecomplicated in that they express multi-dimensional combinatorial specs.A very common example is the combination of pants waist and inseamsizes, that are usually available in some but not all possiblecombinations. Here is an example:

Waist size* Inseams Available Colors avail. 22″-28″ 26″-34″ Black, Navy,Tan, Forest 29″-39″ 28″-42″ Black, Navy, Tan, Forest 40″-44″ 30″-44″Black, Navy *Odd and even sizes available **Even sizes available

Note that not only must the table be parsed, but the annotations must beunderstood, in order for the scraper to actually assemble the following“canonical” table:

Waist size* Inseams Available** (inches) (inches) Colors Available 22-2826, 28, 30, 32, 34 Black, Navy, Tan, Forest 29-39 28, 30, 32, 34, 36,38, 40, 42 Black, Navy, Tan, Forest 40-44 30, 32, 34, 36, 38, 40, 42, 44Black, Navy

The system must be configurable to force some attribute values todefault to “no” or “none” when there are multiple sources which aresilent about the attribute, and not a single source has mentioned it.This is needed because of the tendency marketers have of not mentioningwhen their product lacks a feature, and mentioning it only when theirproduct does have the feature. For example, only a few of the higher-enddigital cameras might have an interchangeable lens. It is virtuallyguaranteed that if a product page makes no mention of this feature atall, then the camera does not have one. However, no marketer will missthe opportunity to boast of their camera having this type of lens, if itdoes. Therefore the system can detect this pattern and begin to defaultto “no” on the attribute “interchangeable lens” when it has foundmultiple reliable sources that fail to mention the feature for aparticular camera.

Supplemental keyword generator 812 analyzes every product informationrecord with reference to open-ended keywords for each category, ratherthan for normalized specs. These follow from the DOM analysis, in thatthe system recognizes strings or tokens which it appears the productinformation record is putting forward as a spec, and yet do not fitneatly into any pre-defined specs within the system. This catches sospecial one-off specs that otherwise would fall between the cracks. Forexample, among 50 different baby-car seats there may be just one or twowhich say “one-hand harness release” where this feature is not arecognized and normalized spec within the category attribute listing.Nonetheless, that it is presented by a couple of product informationrecords right along with the other specs for the same car seat, enablesthe system to, as it were, add the phrase as an “appendix” of sorts, tothe normalized specs. This is a very powerful feature for (1) categorieswhere there are many esoteric and unique features that are not worthnormalizing or (2) helping the system administrators stay on top of newemerging specs that appear as manufacturers add new features to theirproducts (the administrators will be alerted and review cases where alarge number of overlapping supplemental keyword specs have been addedfor a particular category, to see if the case constitutes a new specthat should be added in a normalized manner).

Property aggregator module 814 of the preferred embodiment is a votingengine which assigns some product information records a greater weightthan others, and then attempts to merge the scraped specs from allProduct Information Records for a particular product, to arrive at afinal set of specs. This resolves contradictions which are very commonlyfound among multiple sources. The property aggregator assigns greatsignificance to finding multiple attestations for a spec-defined ashaving multiple sources of data that have a different format (thereforeapparently not being mere clones of one another) yet agree on theessential content of the specs in question.

The weights can be automatically set or manually set. The automaticsetting is a result, over time, of how often the product informationrecord has been countermanded in the final result. It is possible for aweighting to set either globally over the entire product informationrecord, or just for one category, or just for one attribute in onecategory, or just for one value of one attribute in that category, orjust for one manufacturer of products in that category. Also there is aseparate weighting for image reliability, globally, per category, permanufacturer, and per manufacturer-in-category.

Chief components of the allied products module of the preferredembodiment are:

1) a product relations tool for manually defining accessory relationsbetween products and categories, with constraints; and for viewing ormanually overriding specific products' assignments as allied productsthat have been made automatically; and 2) an allied products engineincluding logic and algorithms for combing the raw source data whenceaffiliated product relations will be automatically “discovered.”

All of the following relations are definable:

Category-to-Category relation: Stipulates that products within categoryA are allied to products within category B. A property constraint isoptional. For example, Compact Flash Cards may be allied to the categoryof PDA's, with the constraint that the memory module type for a PDA mustbe “Compact Flash” in order for the relation to obtain.

Category-to-Product relation: Stipulates that a category of products areallied to a particular product. An example would be “XBOX Cartridges”which, taken as an entire category, are allied to the particular product“XBOX Game Console.”

Product-to-Category relation: Stipulates that a particular product isallied to an entire category of products, with an optional constraint,e.g. that a particular leather case is allied to the entire category of“digital cameras” with the constraint that their property of “formfactor” be indicated as “compact.”

Product-to-Product relation—Stipulates that a particular product isrelated to another particular product, e.g. that a particular modelprinter cartridge is allied to a particular model photo-printer.

A software tool can be provided that allows all the foregoing relationsto be defined manually, with or without constraints, optionally markedas “potential.” A software tool can be defined to allow a user todesignate the allied product type as one of “accessory” or “part” or“supply” etc. Also there are “highlighted” types within each type—thosewhich human editorial knowledge dictates as being of special interest.In the absence of manually highlighted relations for each product, thediscovery engine auto-highlights the highest scoring relations,eliminating closely resembling products (using category and fuzzy namecomparisons) in order to give variability in the top 3 highlightedrelations (e.g. you might want to simply highlight the size variationsof the same Compact Flash card, even though they may have the highestscore). A software tool can be provided to allow a potential relation tobe negated, i.e. for a user to indicate that a category should not beconsidered allied to another. This is to help the discovery engine avoiderroneous or wasteful processing. This is achieved by making a potentialcategory-category relation with a manual score of 0.

Allied Products Module 818 includes algorithms to identify whichcomponent of various product information sources is the “allied productstable” within the web page or other source. For example, which part ofthe HTML template of a merchant's web page is reliably found to be itsaccessory listing. This is accomplished by visiting the merchant pagesand looking for references to current high scoring and manual relations,then identifying and recording the area in the page where these linksare found. Subsequent visits to the merchant sites can use thisinformation to adjust the scoring accordingly, depending on where linksto possibly related products are found on the page. The Allied ProductsModule 818 follows links found in the various allied products tables andchecks for products in known categories. When the scanner has found nrepeated instances of products in the same category for products in thecategory it is currently scanning, it will auto-create the appropriatecategory-category relation, marked as “potential,” and notification canbe provided to the appropriate category manager, through email oranother communications channel.

The Allied Products Module 818 generally operates in accordance with thefollowing algorithm to effect allied products step 916:

1. For each product in a category

-   -   a. Get all merchant offers, for each merchant (this part is        multi-threaded):        -   i. Load and parse the merchant's web page (also, cache the            page)        -   ii. Look for links on the page to “related products”        -   iii. If there are links on that page that lead to auxiliary            accessory pages, then follow the link and go back to 1.a.i.        -   iv. Reverse look up product references and relate them back            to the catalog, compute a product relation score and record            the mapping and the score.

2. Calculate a final product relation score.

-   -   Each of these algorithm steps will now be explained in detail. A        main challenge of the Allied Products Module 818 is to be able        to realize when a merchant is referring to a product on its web        page. Due to variability in the expression of product names, the        only reliable way to specifically identify a product is through        “merchant SKUs”, or the unique product identifier that the        merchant uses to refer to a product. In order to be able to        recognize that a link on the merchant's page actually refers to        a product already in the catalog, it is necessary to perform the        step of “merchant SKU discovery”. The first time that the Allied        Products Module 818 searches the URL of a merchant, it looks to        see if it has done this before. If it has not, the program loads        all of the URLs from the merchant that are present in catalog        26. The URLs are compared to each other and the variable part is        determined to be a SKU. These SKUs are recorded for each        merchant, with mappings back to product Ids in catalog 26, along        with the delimiting characters that help to isolate the merchant        SKU from the URL. When a URL is encountered on the merchant's        page, the URL is dissected using the delimiters, and each        sub-string the URL is searched for in the list of SKUs        previously recorded from the merchant. If a match is found, then        the Allied Products Module 818 knows that the URL refers to a        product in the catalog.

Often, when the Allied Products Module 818 processes a merchant page, orother product information source, to look for related product links, themerchant has decided to put the list of products on another page, e.g.http://www.buydig.com/shop.php?prod_id=CNPSA70&adv=cnet. In such a case,the Allied Products Module 818 must analyze the language in links likethis, and follow them in order to find the product relations. The AlliedProducts Module 818 can use a mini-lexicon and can include theconfidence that this link actually refers to accessories for the givenproduct to the eventual scores for each resulting product reference.Sometimes links to accessory listings may actually be small images. OCRcan be used in a known manner to get the text out of the image.

Many factors go into calculating a product relation score for relationsthat are discovered for each merchant. These can include:

-   -   Providing a higher score based on whether the related product        was manufactured by the same company.    -   If the link includes language such as “ . . . for . . . ”, then        the remaining part of the text is examined to see how well it        matches, and the score is increased or reduced accordingly. This        must take into consideration references such as “for Palm 500        series”, in which case it must be determined that a Palm 515        should get a bonus; as the word “series” indicates that the 515        is part of that. In contrast, if the link said “for Palm 505        only”, then the presence of the word “only” would indicate that        a Palm 515 relating to this product should get a lower score.        This kind of analysis requires identification of model IDs, and        recognition of different types of including/exclusion language,        as well as series specification and matching of model IDs.    -   If the link includes a generic reference to entire categories or        products, then a bonus is given if the category verbiage        matches, e.g. “Viking MMC32M 32 MB MultiMedia Card for a MP3        player, PDA or digital camera”, when the PDA category is        scanned, for example. This requires good lexicon synonym        coverage for category names.    -   Parsing HTML document from the merchant and when a link is        found, the “group text concept” occurring prior to the link is        searched for. For example, the heading before a set of related        product links may be “Add-ons”, or “Accessories for the XXX”,        etc. This is difficult, as there are a number of ways a merchant        may do this in HTML. Placement, text characteristics, and        language are all considered when looking for what these product        links might refer to. When the group text concept is found, the        score is increased if the language indicates that the list of        links constitutes related products. The score is reduced for        other types of relations, such as “Other people who bought this        product also bought these . . . ”. Sometimes these “headers” are        actually small images, so using OCR to get the text out of the        image must be used in these cases.    -   Discarding references to the products within the same category.    -   Considering the price of the related product, as generally an        accessory of a major product will cost less than a major        product, such as a digital camera or notebook computer.

Once all of the relations have been gathered for a product from all ofthe merchants, then the overall relation scores are calculated. Thefollowing can be factors in the computation:

-   -   All of the merchant references are gathered, and higher scores        are given to related products that were referred to by more than        one merchant. This is not entirely reliable, as not all        merchants may carry the product being scanned, for example there        may be only 1 merchant in our list of merchants for a given        product.    -   The merchant rating (set manually by the catalog editor) for how        well it specifies related products increases or decreases its        contribution to the overall score for a given relation.    -   The Potential Category-Category relations are taken into        consideration and also contribute to modifying the score, both        positively and negatively depending on the score of the        potential relation that was previously discovered.

When a whole category of products has been scanned, the following can beconsidered, in order to determine if the whole category itself can beallied to some products or to some other categories:

-   -   Category counts—the total number of related products in each        category are counted up. Categories with more related products        in them are more likely to be validly related on the whole as an        allied category of products, so the scores are adjusted        accordingly based on the category counts. For example in the        category of “Handheld Device Cases”, nearly every product within        this category will already have a relation (or many relations)        to other products. This fact indicates strongly that the entire        category itself, i.e. “Handheld Device Cases” has a better        chance of being itself validly related to some products as an        allied category of products.    -   Give score penalties for the related category being a        “miscellaneous” type of category—although such a category may        contain some products that would have valid relations, generally        the miscellaneous category, on the whole, is not relevant to any        particular product.    -   Give a score penalty for relations from sibling categories,        since, so long as the category tree is well conceived, such        relations are usually bad (e.g. a desktop related to a        notebook).    -   The catalog editor may mark certain categories as being better        or worse for the likelihood of having related products, and the        system will use that information to adjust the scores (these are        the Potential Category-Category relations?).    -   If the scores pass a scanning threshold, then they are saved to        the database, where the scores may be manually overridden if        need be. There are actually two thresholds, a “scanning        threshold” and a “publish threshold”. If the “scanning        threshold” is met, the relation is saved, even though it may not        get published. The idea here is that a good relation may get a        low score for some reason but that the user may manually        override the score if the relation is deemed worthy of        publishing.

A final pass for each product is to “highlight” the top 3 (or top n)products. The highlighted related products are composed of the highestscoring products, as well as the products that are not too similarlooking (in order to give a good variety to the user when the relatedproducts page is first viewed). The Allied Products Module 818 takes therelation with the highest score, then moves onto the next one, checkingthe category that it is in and similarities in the product names. If theproducts go over a similarity threshold, then the second product is nothighlighted, and the system moves onto the third highest scoringrelation, and so on. A catalog editor may manually highlight products,and these take precedence.

Sometimes many relations are found that are very similar, making thebrowsing of these products tedious. The Allied Products Module 818provides clustering information that allows the application, such as aweb browser to optionally show the highest scoring relation in a clusterand not show others, but instead show a “more like this . . . ” link.The clusters are created using the opposite logic of the highlightingphase, and score relations on their similarity, including the category,manufacturer, fuzzy product name match (particularly differences thatfocus on variant-type language, including differing by one attribute,etc.), manually created cluster patterns, price, etc.

Once the allied products list is created and saved, product informationrecords can be retrieved from merchants for products in accessorycategories marked in the taxonomy. Product links or language that wouldsignify what products/models this is allied to can be located by doing alook up in a product database and assigning confidence levels to theresults using known sophisticated parsing techniques. The results fromall merchants can be aggregated, a voting mechanism can be applied, andanother list can be created. Both of these lists of relations can beused to derive an aggregated score. If the score is greater than apredetermined threshold, then the Product-to-Product link can be createdin the table. This can include an inference to other product relationsbecause of the main product being in a product line, e.g. one case mayfit all Palm M series.

On second-pass scanning, only “potential” relations will be considered;the engine will ignore links not found to abide by these potentialrelations; but will archive the items thus ignored. When a certain massof such items has been accumulated (or when a specified time period haselapsed) the first-pass scanning will be repeated.

During the aforementioned procedures of clusterer module 802,categorizer module 804, property scraper module 810, property aggregatormodule 814, description generator module 816, and allied products module818, any number of products or offerings (or relations or bundles) canand will fall below required confidence thresholds. Post processingmodule 820 handles such products. These can either be deferred and saveduntil more data is available for the automated system to work from, orthey can be retained in an incomplete and merely quasi-“UPIDized” form.Alternatively, they can be moved over to a tool for human editors topatch them up as much as possible, e.g. a product may not have hadenough information to classify a TV between CRT TVs and portable TVswith enough confidence, and so an appropriate error status would be set,drawing a human being's attention right to the attribute that is inquestion, so that it can be filled in.

Previous tests of the entire procedure outlined in this documented haveresulted in at least 80% automation (i.e. labor reduction, compared tousing the “brute-force” method of manual data entry) and as high as 96%in some categories, while maintaining comparable accuracy and actuallysuperior normalization to manual methods; this is from a test of overtwenty diverse product categories ranging from action figures to heartmonitors to baby car seats.

Furthermore, it should also be noted that one embodiment of the presentinvention has been described above where the Internet is the networkedcomputer environment and the crawler is a Web crawler. Moreover, in theembodiment described above, the manufacturer's product specificationsWeb pages are deemed to be the manufacturer's product specificationssource and the merchant's Web page are deemed to be the merchant'sinformation source. However, the present invention is not limitedthereto and may be applied to other types of networked computerenvironments and other sources as well. The present invention can beimplemented over any type of communications channel, such as theInternet, a local area network (LAN), a wide area network (WAN), directcomputer connections, or the like, using any type of communicationhardware and protocols. Any type of hardware or combination of hardwarecan be used for the various clients and servers. Accordingly, the term“computer” as used above, refers to any type of computing device or dataterminal, such as a personal computer, a portable computer, a dumbterminal, a thin client, a hand held device, a wireless phone, or anycombination of such devices. The various clients and servers can be asingle computer at a single location or multiple. computers at a singleor multiple locations. For example a server may be comprised of aplurality of redundant computers disposed in co-location facilities atvarious locations to facilitate scalability. Any appropriate server orclient software can be used and any communication protocols can be used.Communication can be accomplished over electric cable, fiber opticcable, any other cable, or in a wireless manner using radio frequency,infrared, or other technologies. Any interface can be used for selectingproducts for purchase. The various information can be stored in anyformat and thus the term “database” as used above refers to anycollection of information such as a database file, a lookup table, orthe like.

Thus, the above described method and apparatus in accordance with theembodiments of the present invention provides a very effective systemand method for aggregating desirable product information. As can now befully appreciated, the present invention facilitates on-line commerce byallowing the provision of important product information to the shopperto thereby facilitate an informed purchase decision by the shopper. Thepresent invention also provides a novel method for efficientlyaggregating such product information from a networked computerenvironment and also provides a novel method for providing updatedproduct information to shoppers thereby facilitating the purchasedecision of the shopper.

The invention has been described through a preferred embodiment. Howevervarious modifications can be made without departing from the scope ofthe invention as defined by the appended claims and legal equivalents.

GLOSSARY

allied product: a product that integrates functionally with anotherproduct—e.g. an accessory (envelope feeder for a printer), part(replacement screen for a PDA), supply (paper or printer cartridge), ormaintenance equipment (tape head cleaner). The differences between theseare significant as regards the exhaustibility of the item, whether aperson typically buys it once, or many times, etc.

associated product: a broad term embracing all allied, variant, familyand bundled products.

attribute value set: the set of all possible values recorded (orrecordable) within the system for a particular attribute.

attribute: a function, relation, quality, quantity, purpose, material,format, structure, or effect produced, of a product. See also property.

categorization: the process of assigning a product to the categorywithin a taxonomy where it most properly belongs.

category: a group of products sharing the same essential propertydefinition as each other and occupying the same node in a taxonomy aseach other.

clustering: the process of collecting into a group the offerings fromdifferent merchants that are of the identical product (or identicalcombination of products).

confidence score: a metric of the confidence that data is correct orreliable, e.g., that a product name or reference has been parsed andidentified correctly being put forth by a data source as an alliedproduct of another product, i.e. how sure is the system that what agiven web page is saying, is that product A is an accessory for productB?

DOM: (Document Object Modeling): analyzing an HTML web page to segmentit into various regions, e.g. header, footer, product spec table,product text description, recommended accessories, cross-sell/up-sellproduct listing, nav bar, ad blocks, etc. This can be a preliminary stepto set up property scraping, item clustering, accessory discovery, etc.

minimum manufacturer name: the resulting string after a manufacturername string has removed from various extraneous or common suffixes suchas “Inc.”, “Corp.” etc.

normalization: The process of identifying attribute names and/orattribute values which have the same meaning but are expressed insuperficially different nomenclature, and mapping them to a single,consistent form of expression.

normalized attribute value sets: attribute value sets that are fullynormalized (see normalization), including any applicableunits-of-measure. The attribute names themselves may or may not benormalized.

normalized attributes: Normalized attributes are those where the name ofeach attribute is normalized—the value set for the attribute may or maynot be normalized.

normalized specs: A set of data consisting of attribute name/value/unitinformation where all of these elements are normalized.

potential relation: establishes a relation as valid by definition butsubject to specific product compatibility testing. E.g. styluses are“potentially” linked to PDAs in general, but are subject tocompatibility.

prior probability: the odds of a random guess being correct out of allthe possibilities that conceptually exist. E.g. in clustering, if thereare 2 products of a given type in the catalog and a new, unknownoffering is about to be analyzed, its clustering has a prior probabilityof 0.33 (reflecting the 1-in-3 chance of its either being the same asone of the 2 products in the database, or being a third new one). A newoffering compared against 99 catalogued products would have a priorprobability for clustering of 0.01. The prior probability can affect theconfidence estimations at various stages of clustering. Priorprobability plays a role, mutatis mutandis, in various other aspects inauto-generation of catalog.

product bundle: a main product combined with any number of accessories,parts or supplies.

property: An attribute that either is intrinsic or else derives solelyfrom perception of or use of the product in respect to its intrinsicproperties. Some attributes of a product such as Brand, Price andDistributor SKU are not properties, as they may derive from otherexternal forces apart from use of the product.

quasi-UPIDized: A set of data representing product offers that havebeen, in most instances, UPID-ized, but where a minority of productoffers are not UPID-ized. (see UPID)

sister product: a similar, though distinctly different product that is amember of the same product line, series, or family, e.g. Palm V vs. PalmVx.

taxonomy: a hierarchical tree, or other grouping of product categories.

UPID: “Universal Product ID” An identifier of one particular productamong its multiple, variously described and variously named offers.Where available, a manufacturer part number, model ID, catalog number,or ISBN number can serve as the UPID. In many cases, no such UPID existsin external data sources and must be created and assigned by the system.

variant product: a version of a product that has a difference in featureconfiguration from the manufacturer or dealer but is essentially thesame product. E.g. a notebook with 128 MB Ram and the same notebook butwith 256 MB RAM.

What is claimed:
 1. A method of effecting commerce in a networkedcomputer environment comprising the steps of: receiving, by a shoppingserver having a database, identification a user of a client computer;receiving a selection of plural products through an integrated shoppinginterface of the client computer, based on product information in thedatabase, for purchase from plural merchant servers that are remote fromthe shopping server; transmitting product information related to theselected products for presentation to the user for confirmation of apurchase; and causing a buy procedure to be executed on the merchantservers for purchase of the selected products from the merchant serversif the user confirms the purchase.
 2. A method as recited in claim 1,further comprising verifying the product information by receivingupdated product information from the merchant servers.
 3. A method asrecited in claim 2, wherein said verifying step comprises verifying theproduct related to the selected products after said selecting step.
 4. Amethod as recited in claim 1, wherein the database comprises a productdatabase having product information and a shopper database havingshopper information.
 5. A method as recited in claim 4, furthercomprising the steps of: checking if there is account information in theshopper database related to the user for the merchant servers; andestablishing an account related to the user with the merchant servers ifsaid checking step indicates that there is not account information inthe shopper database related to the user for the merchant servers;wherein the buy procedure is executed on the merchant computer inassociation with the account information related to the user for themerchant server.
 6. A method as recited in claim 4, further comprisingdisplaying a buy form to the user containing information from theshopper database corresponding to the user and to be used in the buyprocedure.
 7. A method as recited in claim 4, wherein said buy procedureis executed on the merchant servers through an interface of the merchantservers.
 8. A method as recited in claim 7, wherein said buy procedurefurther comprises filtering out form submissions sent by the merchantservers and filling in the filtered forms with information related tothe user from the shopper database.
 9. A method as recited in claim 1,wherein a purchase procedure is executed on the shopping server, the buyprocedure of the merchant servers being integrated into the purchaseprocedure.
 10. A method as recited in claim 3, wherein said verifyingstep comprises accessing a checkout page of each of the merchant serversand downloading the products information related to the selected productfrom the checkout pages.
 11. A method as recited in claim 1, furthercomprising the steps of: establishing a first cookie on the shoppingserver containing a merchant server session identification; establishinga second cookie on the client computer identifying a user sessionbetween the client computer and the shopping server corresponding to themerchant serve identification; and correlating the second cookie with atransaction record established in connection with the first cookie. 12.A method as recited in claim 1, further comprising the steps of:spawning a buy process in the shopping server for accomplishing saidselecting step; and updating a transaction record based on the status ofthe buy process.
 13. A computer system for effecting commerce in anetworked computer environment comprising: at least one processor: adatabase; at least one memory coupled to one or more of the at least oneprocessors and having computer executable code stored therein which,when executed by said one or more of the at least one processors, causesthe one or more of the at least one processors to: receiveidentification a user of a client computer; receive a selection ofplural products through an integrated shopping interface of the clientcomputer, based on product information in the database, for purchasefrom plural merchant servers that are remote from the shopping server;transmit product information related to the selected products forpresentation to the user for confirmation of a purchase; and causing abuy procedure to be executed on the merchant servers for purchase of theselected products from the merchant servers if the user confirms thepurchase.
 14. A system as recited in claim 13, wherein the productinformation is verified by receiving updated product information fromthe merchant servers.
 15. A system as recited in claim 214 wherein theproduct information is verified by verifying the product related to theselected products after said selecting step.
 16. A system as recited inclaim 13, wherein the database comprises a product database havingproduct information and a shopper database having shopper information.17. A system as recited in claim 16, wherein the instructions furthercause the one or more of the at least one processors to: check if thereis account information in the shopper database related to the user forthe merchant servers; and establish an account related to the user withthe merchant servers if there is not account information in the shopperdatabase related to the user for the merchant servers; wherein the buyprocedure is executed on the merchant computer in association with theaccount information related to the user for the merchant server.
 18. Asystem as recited in claim 16, wherein the instructions further causethe one or more of the at least one processors to display a buy form tothe user containing information from the shopper database correspondingto the user and to be used in the buy procedure.
 19. A system as recitedin claim 16, wherein the buy procedure is executed on the merchantservers through an interface of the merchant servers.
 20. A system asrecited in claim 19, wherein the buy procedure further comprisesfiltering out form submissions sent by the merchant servers and fillingin the filtered forms with information related to the user from theshopper database.
 22. A system as recited in claim 13, wherein apurchase procedure is executed on the shopping server, the buy procedureof the merchant servers being integrated into the purchase procedure.23. A system as recited in claim 16, wherein the verifying comprisesaccessing a checkout page of each of the merchant servers anddownloading the products information related to the selected productfrom the checkout pages.
 24. A system as recited in claim 13, whereinthe instructions further cause the one or more of the at least oneprocessors to: establish a first cookie on the shopping servercontaining a merchant server session identification; establish a secondcookie on the client computer identifying a user session between theclient computer and the shopping server corresponding to the merchantserve identification; and correlate the second cookie with a transactionrecord established in connection with the first cookie.
 25. A system asrecited in claim 13, wherein the instructions further cause the one ormore of the at least one processors to: spawn a buy process in theshopping server for accomplishing said selecting step; and update atransaction record based on the status of the buy process.